Seeing Through Darkleech Obfuscation: a Quick Hack to Iframes

This blog post was written by Kalpesh Mantri.

Darkleech is an Apache module on the dark web that distributes malware. This tool, which appeared in 2012, was first used to infect many Apache servers and later sites running Microsoft IIS. The campaign infecting IIS sites was named pseudo-Darkleech because it resembles the Apache infector module. (In this post, we will use the term Darkleech to refer to both Apache and IIS campaigns.)

In early 2012, Darkleech scripts redirected users and led them to Blackhole exploit kit pages. After the Blackhole kit disappeared in October 2013, Darkleech moved to Fiesta exploit kits. From mid-2015 to today, Darkleech scripts switched occasionally between Neutrino and Angler exploit kits to deliver ransomware. Darkleech mostly redirects to Angler landing pages. (A detailed history of Darkleech can be found here.)

Finding Darkleech 

Since late 2015, Darkleech scripts have evolved drastically. They are now highly obfuscated, and we can’t easily determine the URLs they redirect to.

In this post we offer a quick hack for security researchers to find iframes and redirecting URLs from these heavily obfuscated scripts, which are injected into web pages. We will focus only on finding the iframe and URL; we will not discuss the functionality of the scripts or how they work. This hack does not require any special security tools. Using only Notepad and a browser (Firefox in this case), we can see the final iframe and its redirecting URL. This technique makes use of the browser’s “alert box” (message box) feature.

Warning: Do not directly run these scripts on a machine. Use VirtualBox or another virtual machine instead. Also, take caution while making use of the URLs in these scripts. They are usually exploit kit landing pages, which if active exploit vulnerabilities in users’ systems and download malware (mostly ransomware) to infect your system.

Find the sample

For our demonstration, we will use a Darkleech sample we found on VirusTotal that has a low detection rate.

SHA-256: 7ea431ca9980d5f1d92fc105cd89bc897774bbe970db5a8a32dcd6e73ef400ae

This sample has a block of data between <span> tags. The data in this block is highly useful for decoding the final iframe. This data block is decoded using a script that is present just below the <span> block. This heavily obfuscated script lies within the <script> block of the HTML page:

Follow these steps

Near the end of the script, you will find a function call with the following format:

• Function_name(variable_name)();

In the script, the function appears like this:

The variable_name is always a variable used to concatenate the entire script.

First step

Replace the function_name (in this case, fileUploadSetTimeout) with “alert” and remove the function call (the parentheses).

After saving the file and opening this page in a browser, you will see the concatenated script string from this obfuscated code. The script will be displayed in a pop-up alert box.

Copy and clean up the script:

Second step

Append this discovered script to the current HTML sample page just below the first step. These scripts are designed to run only on Internet Explorer. So after appending the script, we need to tweak the script to make it run smoothly on Firefox (and other browsers). Change the script thus:

Modify the original statement at line 12 by changing the value of variable “i” to zero.

Original statement:        i = (+[window.sidebar]) + (+[window.chrome]);

Modified statement:      i = 0;

Also, remove the function call “()” and “[]” and modify the function call statement:

Original statement:        [][c][c](String.fromCharCode.apply(null, a))();

Modified statement:      temp = [c][c](String.fromCharCode.apply(null, a));

   alert(temp);

Save this modified script into same sample. Running the sample again now gives us two alert pop-ups. The second pop-up outputs the concatenated script, which is itself a new deobfuscated script.

Copy this script and clean it:

Third step

Similar to the second step, append this script to the sample just after the second step script. Again, we tweak the script, four times, to make it run in Firefox or other browsers.

Modify the original statement at line 20 by replacing the value of variable “ArrayTry” to zero.

Original statement:        ArrayTry = (+[window.sidebar]) + (+[window.chrome]);

Modified statement:      ArrayTry = 0;

Change the if statement on line 23 to make the condition true:

Original statement:        if (navigator.userAgent.indexOf(pkcs11Typeof[throwImage]) > ArrayTry) {

Modified statement:      if (true) {

Also change the if statement on line 28 to skip the condition:

Original statement:        if (navigator.userAgent.indexOf(“MSIE 10”) > ArrayTry) {

Modified statement:      if (false) {

Finally, remove the function call “()” and “[]” and modify the function call statement:

Original statement:        [][“constructor”][“constructor”](setIntervalInfinity)();

Modified statement:      tempA = [“constructor”][“constructor”](setIntervalInfinity);

   alert(tempA);

Save this modified script into the same sample. Running the sample again now gives us three alert pop-ups. The first two are the same as before. The third pop-up contains the final malicious iframe and URL that redirects the user.

Copy and clean up the script:

We can now easily see the document.write function call with iframe and URL.

Conclusion

With this simple three-step hack, anyone can easily analyze any Darkleech-injected obfuscated scripts to find the redirecting URLs. With the URLs, we can see which exploit kit landing page the script redirects to. Usually, these URLs are active for only a very short time.

Introducing McAfee+

Identity theft protection and privacy for your digital life

Download McAfee+ Now